Was ist Software-Architektur? Verschiedene Sichtweisen
Die englische Wikipedia versteht unter dem Begriff „Software Architecture“ sinngemäß: Die Festlegung auf bestimmte Strukturen, Beziehungen zwischen diesen Strukturen sowie die Eigenschaften der Strukturen und Beziehungen.
Diese eher allgemein gehaltene Definition funktioniert in der Praxis schon ganz gut. Je nach Flughöhe, aus der ein System betrachtet wird, werden die Begriffe unterschiedlich mit Leben gefüllt. So lässt sich diese Betrachtungsweise sowohl auf der Ebene von (Micro-)Services als auch auf der Ebene von Schichten bis hinunter zur Ebene von Klassen anwenden. Das verdeutlicht aber auch, dass sich eine Architektur immer nur in Abhängigkeit vom Betrachtungswinkel definieren lässt.
Betrachtet man die Ebene der Klassen, Methoden und Funktionen, wird sich manch einer daran stören, hier auch von Architektur zu sprechen. Folgt man der gegebenen Definition, muss das aber nicht zwingend falsch sein. Vielmehr kann eine Regel, die besagt, dass private Methoden keine öffentlichen Methoden derselben Klasse aufrufen dürfen, durchaus als Teil der Architektur angesehen werden.
IMMER AUF DEM NEUESTEN STAND BLEIBEN?
Dann abonnieren Sie unseren Newsletter und erhalten Sie Updates zum Event, Infos über neu erschienene Blogartikel und weitere Themen rund um Softwarearchitektur
Die Möglichkeit, eine Architektur aus unterschiedlichen Flughöhen, also in unterschiedlichem Detailgrad zu betrachten, ist einer der besonderen Aspekte des C4-Modells, das bei uns mittlerweile in verschiedenen Projekten zur Anwendung kommt. Dieses Modell erlaubt es uns, mit Hilfe einer simplen grafischen Notation die Architektur unserer Systeme auf unterschiedlichen Ebenen darzustellen.
Auf der obersten Ebene, im Modell als Kontext bezeichnet, wird abgebildet, wie unser betrachtetes System in die existierende Systemlandschaft eingebunden wird und welche Beziehungen es zu externen Systemen gibt. Auf der Ebene darunter finden sich die Containerdiagramme. Auf dieser Ebene werden die unterschiedlichen Laufzeiteinheiten wie Anwendungen oder Datenbanken betrachtet und die Beziehungen untereinander dargestellt. Eine Ebene tiefer werden die Komponenten innerhalb eines Containers und ihr Zusammenspiel sichtbar. Auf der untersten Ebene schließlich erfolgt die Darstellung von Codediagrammen, wie z. B. Klassen. Hierfür setzt das C4-Modell auf die existierenden Notationen aus der UML. In den technischen Umsetzungen, die es für dieses Modell gibt, bietet sich dann die Möglichkeit, von einer Ebene in die nächste zu springen und so interaktiv einen Einblick in das System zu erhalten.
Die Flughöhe, also der Detailgrad, in dem man von oben auf ein System schaut, ist aber nur eine der Dimensionen, die in Bezug auf die Architektur betrachtet werden können. Daneben können ebenso konkrete technische Strukturen (z. B. Layer), fachlich getriebene Konstruktionen (z. B. Packages im Domain-Layer) oder allgemeingültige Aspekte, etwa die Zyklenfreiheit, untersucht werden. Genauso lässt sich zwischen der Architektur der Anwendung und der Infrastruktur, innerhalb derer sie bereitgestellt wird, unterscheiden.
Es ergibt also Sinn, Architektur eher bezüglich einer bestimmten Sicht auf die Anwendung zu verstehen. Je nachdem, in welchem Teil des Lebenszyklus sich die Anwendung befindet, kann die Wichtigkeit einer bestimmten Sicht überwiegen. So ist es zu Beginn sicher sinnvoll, zunächst über die technische Architektur zu reden, um ein grobes Rahmenwerk für die Entwicklung zu haben. Besteht die Anwendung zu Beginn nur aus wenigen Features, ergibt die Diskussion über die Architektur aus fachlicher Sicht noch wenig Mehrwert. Je mehr die Anwendung dann aber in fachlicher Hinsicht wächst, wird auch die Betrachtung der fachlichen Architektur immer wichtiger.
Lebende Architektur
Anders als die Architektur von Gebäuden ist die Softwarearchitektur etwas Lebendiges und eben nicht – wie allzu oft angenommen – in Stein gemeißelt. Es wäre geradezu vermessen, anzunehmen, dass der erste Wurf einer Architektur den stetig wachsenden Anforderungen gewachsen ist. Dieser Blick aus dem Elfenbeinturm heraus richtet oft eher Schaden an.
So wie Software im Laufe der Zeit wächst und sich verändert, muss sich auch deren Softwarearchitektur mit der Zeit wandeln und sich neuen Anforderungen und Gegebenheiten anpassen. Das bedeutet nicht, dass die Architektur, mit der die Software ins Leben gerufen wurde, falsch sein muss. Im Gegenteil: Zu Beginn der Entwicklung kann sie genau richtig auf die Bedürfnisse ausgerichtet gewesen sein und das Gefühl vermittelt haben, dass sie die Entwicklung stützt und Leitplanken vorgibt.
Wie die Erfahrung aber zeigt, wirken viele und unterschiedliche Faktoren auf ein Softwaresystem ein und zerren es mal in die eine, dann in die andere Richtung. Aus diesen Änderungen lernen wir (hoffentlich) und passen unsere Entwicklung entsprechend an. Nur, wenn sich die Architektur ebenso als flexibel und anpassungsfähig erweist, kann sie auch weiterhin ihre stützende und leitende Funktion erfüllen.
Zeigt sich eine Architektur hingegen als starr und änderungsresistent, wird sie mit der Zeit immer mehr ein Hindernis sein. Es müssen dann meist immer komplexere Lösungen gefunden werden, um in dem bestehenden Korsett auf neue und veränderte Anforderungen reagieren zu können.
So flexibel wie der Begriff und die Funktion von Softwarearchitektur sollte unserer Meinung nach auch der Begriff des Softwarearchitekten verstanden werden. Architekt zu sein sollte vielmehr als eine Rolle verstanden werden, die jeder im Team übernehmen kann. Dabei muss nicht jeder auf jeder Ebene und in jedem Bereich den vollen Durchblick haben. Vielmehr reicht die Erkenntnis: In dem Kontext, in dem ich mich gerade befinde, passt die Architektur nicht mehr, hier muss etwas geändert werden.
LUST AUF MEHR SOFTWARE ARCHITEKTUR?
Zahlreiche aktuelle Themen wie KI, LLMS und Machine Learning, sowie Frontend-Architektur, für Tools zur Softwarearchitektur, Cloudlösungen und Software beweisen.
Praktische Architektur
Was ist denn nun aber eigentlich eine gute Architektur? Das lässt sich schwer verallgemeinern. Überspitzt gesagt gilt jedoch: Wenn klar ist, wo etwas hingehört, hat man schon einen guten Schritt gemacht. Man darf hier jedoch nicht in Extreme verfallen. Gibt es nur einen Ort, ist klar, wo alles hingehört. Gibt es zu viele Orte, und nur ein Experte kann kleine Unterschiede erkennen, die für den einen oder anderen Ort sprechen, führt das eher zu Verunsicherung. Hier muss eine gute Balance gefunden werden.
Ist eine passende Architektur gefunden – zumindest für den Moment –, so gilt es, diese auch auf das System anzuwenden. Vor allem die Platzierung von Komponenten und deren Interaktion untereinander lassen sich mit Tools wie ArchUnit oder jqAssisstant in Regeln ausdrücken, die als Testfälle automatisiert ausgeführt werden können. Somit lässt sich z. B. im Rahmen der CI-Pipeline sicherstellen, dass sich neuer Code in die definierten Architekturregeln einfügt.
Wenn sich die Architektur im Laufe der Zeit wandelt, ist es notwendig, die Änderungen bewusst und nachvollziehbar auszudrücken. Für diese Zwecke hilft es, die Entscheidungen bezüglich der Änderungen in einer eindeutigen Form zu dokumentieren. Hierfür etabliert sich immer mehr das Konzept der Architecture Decision Records (ADR). Diese ADR geben einen Rahmen von anzugebenden Informationen vor, die Aufschluss darüber geben, warum eine bestimmte Entscheidung getroffen wurde. Hierzu gehören sowohl der Kontext, also die Umstände, die die Entscheidung notwendig gemacht haben, und eine genaue Beschreibung der Entscheidung, als auch eine Auflistung von positiven und negativen Folgen, die diese Entscheidung mit sich bringt.
Eine weitere Form der Dokumentation, die eigentlich selbstverständlich sein sollte, kann in Form von Grafiken erfolgen. Es gibt eine Vielzahl von Tools, die es ermöglichen, schnell und unkompliziert Schaubilder zu erstellen, die die Zusammenhänge zwischen Komponenten abbilden. Bilder zu Architektur sagen oft mehr als 1 000 Worte.
Dabei kann eine Architektur nicht selten sichtbar und klar erkennbar sein, ohne dass diese explizit beschrieben wurde. Das ist häufig der Fall, wenn man sich Code anschaut und denkt: „Wow, der Entwickler ist echt gut“. Oder auch einfach nur, wenn ein geplantes Feature deutlich einfacher zu implementieren war als gedacht.
Software-Architektur: Und jetzt?
Kann es eigentlich zu viel Architektur geben? Wann schränkt sie die Kreativität der Entwickler ein? Auf diese Fragen haben wir bislang auch keine befriedigende Antwort gefunden. Softwarearchitektur sollte sich jedoch nicht nach behäbiger Bürokratie anfühlen. Vielmehr soll sie als Leitplanke für die Entwicklung verständlicher und wartbarer Software dienen und eben nicht zum reinen Selbstzweck existieren.
